feat: export the telemetry of divan benchmarks over OTLP - #197

Spans and log records carry wall clock times, which cannot be lined up
exactly with the benchmark markers taken on the monotonic clock: the
wall clock can be adjusted while the benchmarks run.

With instrument hooks, each span carries the times it started and ended
at on the clock of the markers as its `codspeed.monotonic_start_ns` and
`codspeed.monotonic_end_ns` attributes, and each log record the time it
was emitted at as `codspeed.monotonic_time_ns`. Their timestamps stay the wall clock times
of the SDK, as standard tools expect.

The OpenTelemetry layer takes the start time of a span when the
`tracing` span is created, but only starts the OpenTelemetry span when it
is first entered or closed, e.g., on the first poll of an instrumented
future. A layer placed after it starts the span on creation, through
`get_otel_context`, to set the start then. The OpenTelemetry layer takes
the end time when the span is last exited, or closed if it never was, and
ends the span when it is closed. Since the SDK only adds attributes, a
layer placed before it records the time of the last exit, and sets the
end once, when the span is closed.

The SDK batch processors are now built with a queue of 65536 rather than
the default 2048, so that a benchmark emitting on every iteration doesn't
overflow it.

Refs COD-3862
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

…elemetry mode

`tracing` spans and events weigh on the measurements of the code they
instrument. Every build for the simulation, walltime and memory modes
now passes `--cfg=codspeed_tracing_off`, behind which the `codspeed`
crate depends on `tracing` with `max_level_off`: features unification
compiles every span and event of the build out, dependencies included.
Unlike `--features tracing/max_level_off`, it doesn't require each
selected package to depend on `tracing` directly. `--keep-tracing` opts
out, e.g. to benchmark a `tracing` subscriber.

The new `telemetry` measurement mode builds the benchmarks to collect the
telemetry they emit instead of measuring them: they run once like in
simulation mode (`--cfg=codspeed`), keep `tracing`, and land in
`target/codspeed/telemetry`. It builds along other modes, each with its
own flags, e.g. `-m walltime,telemetry`. `--keep-tracing` is rejected
when telemetry is the only mode, since it implies it.

The telemetry build also passes `--cfg=codspeed_telemetry`. The
dependencies exporting the telemetry move to a target table on that cfg,
so the other builds don't compile them, even with the `telemetry`
feature: a benchmark enabling it builds 31 crates of `codspeed` instead
of 157 in measured builds. They only appear in the lockfile of the
projects enabling the feature, as before. Without the cfg,
`telemetry::init` and `telemetry::layer` return `None`, which keeps the
API of the feature. CI checks the MSRV and minimal versions, and runs
the telemetry tests, with the cfg.

`release_max_level_*` features still take precedence over
`max_level_off` in measured builds, since debug assertions are off.

Refs COD-3862
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

The first span of the process takes 20 to 30 µs longer than the next
ones to go through the subscriber, and the first event about 10 µs
longer. The first benchmark emitting them took that time, which delayed
its telemetry from the start of its run.

`init` now emits a span and an event once the subscriber is installed.
They carry a `codspeed_warmup` field, which the processors in front of
the exporters drop, and a target the filter always lets through at the
`error` level, which keeps the max level `log` takes from the filter.

Refs COD-3862
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>